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AUTOMATIC VISUALIZATION OF MANAGED OBJECTS 
5 OVER THE WORLD -WIDE -WEB 

PRIOR PROVISIONAL PATENT APPLICATION 

The present application claims the 
benefit of U.S. Provisional Application No. 
10 60/069,024 filed December 10, 1997. 

CROSS-REFERENCE TO RELATED APPLICATION 

The present application is related 
to U.S. Patent Application No. / / 

15 filed December , 1998, entitled "AUTOMATIC 

AGGREGATION OF NETWORK MANAGEMENT INFORMATION 
IN SPATIAL, TEMPORAL AND FUNCTIONAL FORMS", 
and based on U.S. Provisional Application No. 
60/069,007 filed December 10, 1997. 

20 

BACKGROUND OF THE INVENTION 
FIELD OF THE INVENTION 

The present invention relates to the 
automatic visualization of managed objects 
25 ove\r the world-wide-web, and more 

particularly, to the use of an Aggregation 
Managed Object (AMO) to provide a user- 
friendly interface to view an aggregation of 
management information . 

30 

DESCRIPTION OF THE ART 

The main challenges in providing 
powerful and comprehensive network management 
services for today's integrated networks lie 
35 in three main areas: how to provide support 
for heterogeneity (components of different 
types from different manufacturers) , 
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scalability (large numbers of network 
elements) , and easy access to network 
management services (aggregation and 
visualization of management information) . 
5 The first challenge, heterogeneity , 

is being addressed through standardization 
efforts within organizations such as the IETF 
and the Network Management Forum. Today, a 
number of specifications are available for 

10 managing TCP/IP stacks (MIB-2 and RMON) , ATM 
switches, etc. 

There are, however, no widely 
established methods for dealing with the 
second challenge, that is with the large 

15 numbers of network elements (scalability) . 
Managing large networks requires powerful 
abstractions that capture the essentials of 
the state of the network rather than the 
details. Most approaches for reducing state 

20 and event information in commercially 

available network management (NM) platforms 
are ad-hoc and usually customized for a 
particular management problem or network. As 
networks grow larger and integrate an ever 

25 increasing number of services, the existence 
of a' scalable network management architecture 
becomes critical. 

The first generation of network 
management tools to face the challenge of the 

30 large numbers of network elements 

(scalability) , such as HP Openview, Sun Net 
Manager, IBM Netview, etc., follow closely the 
point-to-point management model. According to 
this model, a network management application 

35 (NM client) connects to a management agent (NM 
server) using one of the standard protocols 
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for management such as SNMP or CMIP. The 
agent contains information about a network 
element or a group of elements. A network 
manager retrieves or controls this information 

5 by issuing "get" and "set" operations. 

Especially in SNMP systems that do not support 
rich data types, this exchange of management 
information is at a very low level. As a 
result, all the intelligence for providing 

10 more complex NM services resides within the 

client (manager) . First generation tools are 
therefore characterized by complex and 
expensive clients. Although these clients 
have the capability to maintain a hierarchical 

15 topology map and thereby provide easier 

navigation through a possibly large network, 
the manager still has to employ a low level 
management protocol to interact with every 
network element. First generation systems 

20 offer few capabilities to customize the avail- 
able management services beyond the 
functionality offered by the underlying NM 
protocol such as SNMP or CMIP, or the 
interface provided by a vendor-supplied 

25 element management system. 

Second generation NM systems have 
tried to address some limitations of the first 
generation by providing better customization 
options and automation of routine management 

30 applications. Tools such as Tivoli's TME 10, 
CA's Unicenter TNG and NetExpert are targeted 
at the corporate IT infrastructure and offer a 
richer set of management services including 
end-to-end application management, network 

35 services management, software distribution 
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Although the above tools simplify, 
to a large extent, the effort required to 
manage large numbers of network elements and 
applications, they are customized to work with 
5 specific products and network protocols. 

Fundamentally, the network manager has little 
control over what management services are 
presented to him/her and how information is 
aggregated, stored and visualized. 

10 The third challenge then, a related 

area that has received much attention 
recently, is the one of access to network 
management services by the manager 
(aggregation and visualization of management 

15 information). Large network management 
systems collect a tremendous amount of 
information from network elements and make it 
available to network operators in a myriad of 
formats. In order for this information to 

20 convey the essence rather than the details of 
network state, it must be organized, 
summarized and simplified as much as possible. 
Similarly, the network manager needs mecha- 
nisms that aggregate the control of a large 

25 number of network elements into simpler 
interfaces . 

Traditionally, network management 
systems have employed proprietary user inter- 
faces to monitor and control a network state. 

30 Such systems are often customized for the 

specific management problem at hand and then 
used by a small group of appropriately trained 
people. This has been an acceptable solution 
while the only users of network management 

35 services were a small number of network 
operators. This situation, however, is 
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changing rapidly: the Internet is reaching an 
increasing number of people and businesses 
every day, and broadband access is coming soon 
to every home. A large number of networked 

5 services are available today for businesses 
and consumers, ranging from simple dial-up 
network access to virtual networking, 
financial services such as online trading and 
banking, one step shopping, etc. The 

10 increasing complexity of online services of 
every form has introduced significant 
management requirements on both service 
providers and subscribers. Service providers 
have realized that the bundling of customer 

15 management services can be an important 
differentiator for their products. More 
customers today require the ability to observe 
the operational state of their service in 
real-time, collect statistics on service 

20 usage, customize parameters of the service, 

order additional service or perform proactive 
management tasks in anticipation of efforts. 
By delegating some aspects of managing a 
service to customers, operators can cut down 

25 on their customer care costs while providing 
competitive and cost effective services. 

The increasing availability of 
management services has motivated many 
researchers to rethink the way these services 

30 are provided to consumers. The continuation 
of the existing status quo which calls for 
customized and complex user interfaces to 
service management functions receives 
increasing resistance from businesses and 

35 consumers that favor portable, lightweight, 
standards-based, solutions that need the 
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minimum amount of configuration and are simple 
to use. Many researchers have proposed to use 
the World-Wide Web (WWW) to provide access to 
management services. The Web offers the 
5 widest possible installed base of compatible 
clients (every networked computer is now 
equipped with a Web browser) and a portable 
execution environment based on Java that 
allows Web clients to access arbitrarily 

10 complex information services by downloading 
the appropriate Java applets . 

Access to the management services 
has thus been provided using the World-Wide 
Web and Java, the most widely available tools 

15 today for remote information access. A 

resulting software platform for such access 
was named Marvel (for Management AggRegation 
and Visualization Environment) which is 
detailed in the reference "MARVEL: A Toolkit 

20 for building Scalable Web-based Management 

Services", and which is hereby incorporated by 
reference. Marvel is a software environment 
that allows the network manager to define how 
management information collected from network 

25 elements is aggregated into more useful 

abstractions and finally presented to the 
manager. Marvel thus provides scalable 
solutions for systems management for small 
businesses and large enterprises, network 

30 management services for network operators, and 
customer network management services for 
businesses and consumers. 

The MARVEL architecture consists of 
lightweight clients and a hierarchy of 

35 Management Aggregation and Visualization 

Servers (MAVS) . The minimum requirement for a 
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MARVEL client is to have a Java Runtime 
Environment ( JRE) . All the necessary code to 
access management services provided by AMOs 
can be downloaded in real-time from the MAVS . 
5 In addition, if the client has the capability 
to display the Hypertext Markup Language 
(HTML) it can use the visualization features 
provided by the MAVS that aggregate attribute 
specific user interfaces (applets) on HTML 

10 pages. This is why Web browsers are the ideal 
MARVEL clients. In addition, the MARVEL 
architecture benefits from the fact that Web 
browsers are very widespread. By making the 
minimum number of assumptions for the client, 

15 MARVEL provides network management services of 
arbitrary complexity to practically every user 
on the Internet. 



WO 99/30423 



8 



PCT/US98/25998 



SUMMARY OF THE INVENTION 

Accordingly, the present invention, 
which can use the Marvel platform (which in 
one embodiment uses a Java-enable Web 
5 Browser) , provides a management information 
model that allows the aggregation of 
management information to reduce complexity, 
and further provides a distributed object 
services model (based on the MAVS described 
10 below) that allows the definition of rich data 
types and management services and the storage 
of management information in a distributed 
database of aggregated information. 

Through the management information 

15 model, the network manager can define how 

management information, collected from network 
elements, is aggregated into more useful 
abstractions and finally presented. 
Aggregation of the information can be 

20 accomplished in spatial, temporal and 

functional forms. To allow for aggregations, 
network elements are grouped according to a 
specified criteria, and an aggregation rule 
specifying what information is sought is 

25 applied to the group. On the basis of the 
aggregation rule, attribute values of the 
network elements are retrieved and a filter 
function is applied. The filter function 
determines a current value of the attribute 

30 across all of the network elements to which 
the aggregation rule is applied. The current 
value of the attribute is then stored in an 
Aggregation Managed Object (AMO) . 

Through the distributed object 

35 services model the AMO can be stored, 

retrieved and automatically visualized over a 
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distributed computing environment such as the 
world-wide-web. Each AMO contains a list of 
attributes which corresponds to network 
management information aggregated according to 
5 the aggregation rule. To visualize the 

information contained within the AMO, a web 
browser contacts the distributed object 
services model (having an HTTP server) which 
in turn creates an HTML page on the basis of 

10 the attributes contained within the AMO. Some 
of the attributes contained within the AMO are 
pointers which point to Java applets stored in 
an applet database. The Java applets are 
retrieved and inserted into the HTML page for 

15 viewing. 

The present invention, including its 
features and advantages, will become more 
apparent from the following detailed 
description with reference to the accompanying 
20 drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 illustrates an example of a 
group hierarchy in a network with 8 managed 
25 elements A to H, according to an embodiment of 
the present invention. 

Figure 2 illustrates an example 
where network elements are organized into 
30 different groups according to various levels 
of aggregation, according to an embodiment of 
the present invention, 

Figure 3 illustrates a 3-level 
35 architecture for generating computed views of 
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management information, according to an 
embodiment of the present invention. 

Figure 4 illustrates a flow chart 
5 for a method of computing an aggregated 

attribute value, according to an embodiment of 
the present invention. 

Figure 5 illustrates another example 
of the attribute value computation procedure 
10 along with a partial apparatus implementation 
of the Marvel software environment, according 
to an embodiment of the present invention. 

Figure 6 illustrates an example of 
15 the apparatus structure of the Management 

Aggregation and Visualization Server (MAVS) , 
according to an embodiment of the present 
invention . 

20 Figure 7 illustrates an example of 

an indirect object visualization procedure 
through an HTTP server, according to an 
embodiment of the present invention. 

25 

DETAILED DESCRIPTION 

Figures 1 through 7 illustrate a 
method and apparatus for providing a 
management information model and a distributed 

30 object services model. The models allow for 
the automatic aggregation of network 
management information in spatial, temporal 
and functional forms, and the automatic 
visualization of managed objects over the 

35 world-wide-web. Network management 

information is aggregated in the form of at 
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least one attribute name-value pair and stored 
in an Aggregation Managed Object (AMO) . The 
AMO is likewise stored in the database of a 
special management agent, the Management 
5 Aggregation and Visualization Server (MAVS) 
which allows a network manager to access 
network information stored in the AMOs . 

For the purposes of the present 
invention, the following methods of 

10 aggregation are distinguished: 

Spatial aggregation, where information is 
collected from a number of components and a 
summarization function (filter) is applied. 
For example, the ingress traffic to a network 

15 region can be computed by summing traffic 
information collected from switches at the 
border of the region. 

Temporal aggregation, where information 
is collected periodically to form a time 

20 series of various granularities (minutes, 
hours, etc.) or, for example, provide an 
autocorrelation measurement . 

Functional aggregation, where information 
from different functional areas of a 

25 management system is combined to construct a 
functional view of a network element or 
service. A subscriber's profile that contains 
the subscriber billing information, CPE 
hardware configuration, performance 

30 measurements, etc., is an example of 
functionally aggregated information . 

The Network Element Grouping 
Model 

35 The main difficulty behind creating 

aggregations is the need to specify and 
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maintain a (possibly) long list of components 
over which the aggregation is computed. 
Sometimes different aggregations are computed 
over the same group of components (which share 
5 a set of commonalities such as location, 
functionality, etc. ) and for this reason a 
network element grouping model can be 
beneficial to reducing the overall amount of 
information required to specify aggregations. 
10 According to the network element 

grouping model, and referring to Figures 1 and 
2, the network consists of a number of 
interconnected network elements (NEs) . 
Network elements are physical devices such as 
15 routers, printers, workstations, etc. 

Usually, the manufacturer of each of these 
elements provides an element management agent 
(EMA) - a rudimentary facility to manage 
(monitor and control) one or more instances of 
20 their equipment in a network. 

Collections of the network elements 
are defined as groups. Users can dynamically 
define groups based on any factor that makes 
sense. For example, groups can be formed 
25 according to geographical or location criteria 
(e.g., a group of all NEs in a building, 
campus, state, etc.), or functionality (e.g., 
a group of all ATM switches) , or some 
combination such as all ATM switches in the 
30 New York City area. 

It is also possible to define a 
group with other groups as members. Thus, 
every network grouping hierarchy forms a tree 
with leaves being network elements. Groups 
35 are not necessarily disjoint. Every group is 
characterized by a level indicator that 
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corresponds to the depth of the tree where the 
particular group belongs. Level 0 is reserved 
for the leaves of a hierarchy which (from a 
network management standpoint) represent the 

5 element management agents. A group at Level 1 
corresponds to a set of element management 
agents. A group at Level 2 may contain groups 
of Level 1 and perhaps one or more EMAs 
(contained in Level 0) . In general, a group 

10 at level n is allowed to contain groups of any 
level lower than n, i.e., level n-1, n-2, . .., 
level 0 inclusive. Some times it is 
convenient to refer to a group of Level 0 
which, however, really implies an element 

15 management agent (or at least one network 
element) . 

For example, Figure 1 demonstrates 
an example of a network with 8 managed 
elements A through H. Each one of these 

20 elements A through H contains an EMA. Two 
groups of four elements each, Gl.l and G1.2 
have been created. Information for these 
groups is stored in objects J and K, 
respectively, which are in turn stored in a 

25 special management agent (i.e., the MAVS, 
explained in further detail below) . 
Furthermore, a second level group G2 . 1 can be 
created which consists of the management 
agent (s) that contain objects J and K. 

30 Information about this group is stored in 

object L. L 1 s attributes are computed from 
the attributes of objects J and K, which in 
turn, are computed respectively from 
attributes in network elements A-D and E-H. 

35 A group can be a point of 

aggregation of information about its 
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subordinates. For example, Figure 2 
demonstrates an example where network elements 
M through Z and AA (of a Level 0 origin) are 
first organized into groups Gl, G2 and G3 that 
5 compose the first level of aggregation. Group 
G4 is defined as the union of Gl and G2, and 
similarly G5 as the union of G2 and G3. Once 
the group hierarchy has been defined, the 
manager can define higher-level management 
10 views and services by referring to groups 

rather than individual network elements. As 
the simplest example, assume that an attribute 
$ ErrorCountg is defined on some EMAs, 
representing the number of unrecognized 
15 packets arriving at the corresponding network 
element. A new attribute "ErrorCountg can be 
defined in a managed object representing Gl to 
represent the total number of errored packets 
received within the group. The latter can be 
20 computed by summing the |£ ErrorCount^ 

attributes retrieved from every member of Gl. 

In general, attributes defined using 
groups of level n are computed by expanding 
these groups recursively to a list of 
25 management agaents. The appropriate 

information is collected from each one of 
these agents to compute the attribute's value. 
Similarly, control operations on an attribute 
are performed by expanding the group 
30 definition into a set of management agents and 
performing a control operation on each one of 
these agents. 

The Information Model 

35 Management information in a large 

network today is usually distributed between 
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the management information databases of 
network elements and, as a consequence, 
represents small aspects of the configuration 
or operation of those elements rather than of 
5 the network as a whole. Network managers, and 
the management applications they use today, 
require access to a much higher level of 
management information and services.. The 
present invention thus uses an object-oriented 

10 information model where the value of an 
object's attribute can be defined as an 
arbitrary computation over other attribute 
values of other objects. Attribute values can 
be information residing inside element 

15 management agents or other computed 

attributes. The emphasis of the model is in 
providing a technology-independent 
specification framework in which these 
computations can be described. Using this 

20 model, the network manager can define new 

managed objects that represent computed views 
(i.e., aggregations) of network management 
information. Computed views can represent a 
summary of lower level configuration and 

25 performance information, or a more detailed 
view of a particular management parameter. 

Referring to Figure 3, objects (such 
as objects J, K and L of Levels 1 and 2 shown 
in Figure 1) representing computed views of 

30 network management information can be regarded 
as implementing a "middleware management 
services" layer 10. This layer 10 extracts 
information from managed elements 20 (such as 
elements A through Z and AA of Level 0 as 

35 shown in Figures 1 and 2) using a standards- 
based management protocol 30 (e.g., SNMP, CMIP 
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or DMI) , processes this information according 
to the computed view specification and makes 
it available to management applications 40 
using a distributed computing environment 50. 
5 Objects within the management middleware layer 
10 can follow the SNMP or OSI structure for 
management information (in which case they are 
accessed using the corresponding management 
protocol) , or a proprietary format that 

10 exports management services to a legacy 
distributed computing environment such as 
CORBA or Java. The model of the present 
invention only specifies the way that an 
attribute value is computed from a set of com- 

15 ponents and for this reason it can be used as 
an extension to standards-based models for 
structuring management information such as 
SNMP, SMI and GDMO. However, the model also 
fits well with a distributed computing 

20 environment such as CORBA, since the notion of 
computed views for network management is 
closely related to the notion of higher level 
management services that can be more ef- 
ficiently implemented in this framework. 

25 The object-oriented information 

model is followed so as to allow storage of 
aggregated management information, as this 
information model captures in a natural way 
the types of management aggregations that need 

30 to be created and the complex relationships 
with the information components from which 
these aggregations are generated. 

The Aggregation Managed Object 

35 Aggregations (i.e., computed views) 

are constructed through an information 
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aggregation process applied to management 
information collected from the network 
elements at Level 0. Every computed view in 
the information model framework is stored in 
5 an Aggregation Managed Object (AMO) and has 
one or more of the following components: 

1. A monitoring view which 
contains information that has been 
collected from the network and pro- 

10 cessed to represent a higher-level 

view of the network state; 

2. A control view which represents 
a control interface to higher-level 
network management services; and 

15 3. An event view, which represents 

notifications that are generated by 
the object following the occurrence 
of a series of other (elementary) 
events . 

20 In order to define a view, the 

network manager specifies an aggregation rule 
with which an attribute value of the view is 
computed. The aggregation rule can be 
specified declaratively , in which case a 

25 description of the aggregation is provided in 
a structured language, or explicitly, in which 
case the manager provides a piece of code that 
will be executed to compute the attribute's 
value. The computed attributes are stored 

30 within the Aggregation Managed Object and thus 
represent the network state corresponding to 
the monitoring and control views. 

The Aggregated Managed Objects are 
stored in the database of a special management 

35 agent (the MAVS - Management Aggregation and 
Visualization Server) which is described in 
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further detail below. AMOs however do not 
abide to a specific network management 
standard either in terms of structure or 
protocol for accessing them. AMOs are 
5 distributed between MAVS for scalability, 
based on a variety of criteria (usually to 
reduce communication overhead between the AMOs 
that are heavily interdependent) . The 
distribution of AMOs to MAVS can be 
10 independent of the grouping hierarchy shown in 
the network element grouping model . 

Aggregated network management 
information is contained within every AMO in a 
list of attributes. Every attribute is 
15 associated with a list of groups to determine 
the information components over which the 
attribute value is computed. In order to 
compute the value of the attribute, the list 
of groups is further expanded into a list of 
20 AMOs or pointers to information within element 
management agents. When the appropriate 
attribute value from each one of these objects 
is retrieved, a filter function is applied to 
calculate the final value. The filter 
25 function operates on the collected attribute 
values and stores the result as the current 
value of the attribute. For example, the 
operation SUM sums all the retrieved values 
and stores the result as the new attribute 
30 value. The operation NULL stores all the 

retrieved values in an array indexed by each 
retrieved attribute. More complex filter 
functions may, for example, compute the mean 
and standard deviation of a distributed data 
35 set, extract topological information to create 
a topology map, etc. 
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More formally, the attribute value 
can be expressed using the following formula: 

V « f {(G, , o, , a, (G 2 , o 2 , a 2 ),...,(G n , o n , aj> 
5 (EQ 1) 

where f is the filter function, G± is a group, 
ai is the component attribute's name and Oi is 
an object selection predicate (i.e., 

10 aggregation rule) . The latter is used to 

select the AMOs or MOs within the group from 
which the attribute value will be collected. 
Note that an attribute need not be computed 
exclusively from components of the same type. 

15 Referring to Figures 4 and 5 , an 

example of the attribute value computation 
procedure is illustrated. In this example, 
the attribute value V is computed from 
information components in groups Gi and G2 - 

20 The procedure works as follows: First, Gi and 
G2 are resolved into a list of element 
management agents. For each agent in group Gi, 
the object selection predicate 01 identifies 
the managed objects that contain the required 

25 information. From each such object, we obtain 
only the values of attributes that correspond 
to the attribute selection predicate ai . The 
group G2 is processed similarly. The result of 
the collection process from all the agents of 

30 Gi and G 2 is stored in a temporary table 

structure (i.e., Intermediate Attribute List) 
that identifies the origin of the attribute, 
its type and its value. The table is then 
used as input to the filter function which 

35 calculates the new value of V. 
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Filter functions can be specified by 
reference, in which case the required code 
segment is loaded dynamically from an external 
function library. The benefit of this 
5 approach is that library functions need not be 
integrated with the MAVS, which allows the 
definition of new functions or the improvement 
of existing ones without disrupting the 
operation of the management system. 
10 Thus summarizing, the information 

model achieves aggregations in a variety of 
ways. Spatial aggregations of an attribute 
can be accomplished through grouping and 
filtering. Temporal aggregations of an 
15 attribute, on the other hand, can be 
accomplished by using special filter 
functions. For example, a sliding window 
filter can store a collected attribute value 
as a time-series. It is also possible to 
20 define new attributes using filter functions 

that operate on the stored time-series such as 
delta functions, cross-correlation functions, 
etc. And lastly, Functional aggregations of 
an attribute can be achieved by combining into 
25 a single AMO attributes whose value is 
computed from a variety of information 
sources . 

For a settable attribute, there also 
exists a mapping function that describes how 

30 the value set by the manager is to be 

propagated to the underlying components. The 
simplest mapping function is the one that 
distributes the same value to all of its 
component attributes. It can be used for 

35 simple on-off operations or control operations 
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that require setting the same value to a group 
of devices. 

A Refresh Policy specifies how the 
attribute value is computed. Computations may 
5 be made either on a synchronous or 

asynchronous basis. In the synchronous basis 
the value is computed dynamically upon an 
operational command or query, such as in a get 
operation of the attribute's value. In the 

10 asynchronous basis, the value is computed and 
stored according to an update condition. The 
latter can be a time interval, in which case 
the value is computed by periodically 
"pulling" information from the component 

15 objects. It is also possible to link the 

computation of an attribute's value with the 
occurrence of an event. For example, an event 
could be an indication that one of the 
component attributes has changed its value. 

20 In an eager policy, the attribute's value is 
recomputed each time any of its components 
change. The choice of the update condition 
must be made with great care: Infrequent 
updates introduce the danger that the computed 

25 information is out of date. On the other 
hand, an eager policy may trigger very 
frequent computations of an attribute's value, 
some of which may not even be necessary (if 
the value is accessed at slower time scales) . 

30 The manager sets the update condition talcing 
into consideration the sensitivity of 
management applications that use this infor- 
mation with regard to its accuracy and the 
complexity involved in computing its value. 

35 Thus, as can be seen, the amount of 

management information kept in an AMO is 
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reduced for the following reasons: Firstly, 
AMO attributes refer to groups of network 
elements rather than the NEs themselves; 
Secondly, values are computed by applying a 
5 filter function to the collected information; 
and, Thirdly, AMOs have the capability of 
evaluating their attribute values 
synchronously upon a query (i.e., operational 
command) , thereby eliminating the need for 
10 storage. 
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Aggregation Managed 
Ob j ect Services 

A distributed object services model 
(i.e., the MAVS described herein below) is 
5 used to provide access to the AMOs. Software 
platforms based on industry standards such as 
CORBA and Java-RMI are gaining momentum within 
the network management services industry and 
can be used to support the present invention' s 

10 framework. AMOs provide network management 
services through a set of advertised 
interfaces. Clients obtain access to these 
services by contacting a service broker. The 
broker returns a reference to the AMO that 

15 offers the requested service. The client then 
invokes operations on the AMO directly and re- 
ceives the results. 

AMOs provide two tiers of services: 
Basic access services, which are mandatory for 

20 all AMOs, and Extended Services that are 

implemented optionally. The latter can be 
used to provide a richer customized interface 
to the object for performing more complex 
operations related to its intended management 

25 function. There are three types of basic 
services : 

1. Attribute access services are used to 
set and retrieve attribute values and 
control several aspects of every 

30 attribute's operation. These functions 

include get (retrieves an attribute value 
as an opaque object) , set, action 
(dynamically downloads control logic that 
operates on one or more attributes or 

35 other objects) , etc. 
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2 , Visualization services are used to 
provide clients with the necessary 
information to setup graphical user 
interfaces (GUIs) to access the object's 
basic and extended services. The benefit 
of this approach is that clients do not 
need to be aware of an object's internal 
structure to provide a user-friendly 
interface. In essence, the GUI is 
"programmed" as part of the object and is 
transferred to the client when it first 
accesses the object. The object may 
provide more than one visualization 
services depending on the type of clients 

15 that are supported by the Marvel system. 

3. Event services are used to subscribe 
internal and external consumers to 
receive event notifications generated by 
the object, and control the event flow. 

20 Events in Marvel are usually aggregations 

of lower-level events corresponding to 
the management view portrayed by the 
object . 

The AMO designer is responsible for 
25 providing an implementation for all basic and 
extended services. Access to the latter can 
sometimes be provided indirectly through the 
basic services. For example, the 
visualization functions can be overridden to 
30 set up a user interface that acc^ssos some of 
the object's extended services. 

In addition to the common services 
provided by every object, every Marvel server 
provides a set of high level services that can 
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be used by client applications to navigate and 

examine the database: 

1. Navigation services are used to 

navigate through the server database and 
5 examine its contents. Current Marvel 

implementations store objects in a tree, 
and include functions like getRoot 
(retrieves the root object), getParent 
(retrieves the parent of an object), 
10 getSubordinates (retrieves the object's 

children), get Path (retrieves the path 
from the root) , etc. 

2. Registration services are used to 
examine the structure and capabilities of 

15 every object in the database. In this 

way, clients can dynamically browse 
through the services provided by the ob- 
ject and invoke a service with the 
appropriate parameters. This 

20 introspection capability does not require 

clients to be previously aware of the 
services provided by every object. 
Rather, services are "discovered" in 
real-time and invoked after loading the 

25 appropriate stub code at the client. 

Objects must register themselves when 
they are created and provide information 
on the attributes they contain, the 
extended services they support and the 

30 stubs that must be loaded to invoke these 

services. 

3. Object management services are used to 
instantiate, upgrade or delete objects 
while the server is running. The manager 
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provides the name of the object to be 
instantiated, its location in the 
database and a pointer to the code that 
can be used to instantiate the object. 
5 The server then dynamically loads the 

code and generates a new object instance. 
Objects can be upgraded, in which case, 
the state of the object is frozen, the 
old code is purged from the agent, the 
10 new code is loaded and the captured state 

is passed to the new object. 

The above services can be 
implemented using industry-standard platforms 
such as CORBA and Java which are currently 

15 being used in many network management appli- 
cations. Java's remote method invocation 
(RMI) is a package that provides distributed 
computing primitives tightly integrated with 
the language, and is extremely easy to use and 

20 integrate into Java applications. CORBA is a 
more widely accepted standard but requires 
more heavyweight implementations. The present 
invention provides the same object services 
under both frameworks: Java RMI is more 

25 suitable for web (and other lightweight) 

clients, while CORBA for more demanding appli- 
cations that require the widest possible 
inter-oper ability . 

30 The Management 

Aggregation and Visualization 
Server (MAVS) 

Referring to Figure 6, the MAVS 1 is 
a management agent designed to handle 
35 aggregations of network management 
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information. Every AMO must be instantiated 
within a MAVS . For this reason a MAVS has a 
number of subsystems designed exclusively to 
support AMO features. Referring again to 
5 Figure 6, its main components are: 

1. The aggregation processing 
engine 2. This engine is 
responsible for implementing an at- 
tribute's update policy by computing 

10 its value from a set of components; 

It initially resolves group 
references into target objects, 
invokes the appropriate protocols to 
collect the necessary information, 

15 and finally applies the filter 

function to compute the final 
value (s). For control operations 
the last two tasks are reversed. 

2. The persistent storage engine 
20 3. By default, the state of every 

AMO is made persistent to survive 
failures of the MAVS . Persistence 
is necessary when the stored 
aggregated information cannot be 

25 reconstructed from the current 

contents of element management 
agents (a time series attribute is a 
good example of an object that must 
be persistent) . 

30 3. The AMO service registry 4. 

The registry logs every AMO on the 
MAVS together with its exported 
service interfaces (basic and 
extended) . Clients first contact 

35 the registry to obtain a handle to 

their AMO of interest. 
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4. An HTTP server 5, that provides 
access to HTML documents generated 
by some AMO's visualization 
functions. It also serves to 

5 download Java class byte code to 

clients and provides an initial 
navigation page to the contents of 
the MAVS object database. 

5. The event processing subsystem 
10 6, that registers event 

subscriptions and performs event 
collections and correlations. 

6. The query processing engine 7, 
that supports operations on AMOs 

15 with user-supplied predicates and 

filters (as described above) . 

7. The protocol translation module 

8. which allows AMOs to access 
management services using a 

20 different protocol, such as SNMP, 

CMIP or CORBA. 

A management system based on MARVEL 
may contain many MAVS. Although it is not 

25 required to follow a particular structure, it 
is usually convenient to structure all MAVS 
similar to the grouping hierarchy for easier 
administration, and to minimize communication 
overheads. So, in a MARVEL system one would 

30 expect to have separate MAVS containing the 
aggregation objects for a particular sub- 
network, a parent MAVS containing aggregations 
about a network region (consisting of several 
sub-networks) , and finally a top level MAVS 

35 containing the aggregations for the entire 

network. In reality however, the management 
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system designer can expand or collapse these 
levels as is necessary. A single MAVS may in 
fact support any number of levels of 
aggregation. 
5 AMOs within a MAVS represent 

aggregations of Levels I and above. The MAVS 
itself acts in a dual role: it acts as a 
server (agent) for its clients and as a client 
(manager) when accessing the services of other 

10 MAVS or EMAs. 

In the current implementation every 
MAVS contains a number of AMOs in a persistent 
storage database, very much like the OSI 
management model. AMOs are placed in a 

15 containment tree structure in any fashion that 
the manager wishes (the tree structure was 
. selected purely for implementation 
convenience) . However, It is often 
appropriate to follow a natural containment 

20 relationship. For example, an AMO 

representing a summarization of performance 
parameters from a set of users would be placed 
as the parent of the AMOs that contain 
performance parameters of individual users. 

25 Note that the structure of the containment 
tree expresses an arbitrary containment re- 
lationship between the AMOs and is not 
necessarily related to the grouping hierarchy. 

Since group definitions and filter 

30 functions can be shared between many MAVS, 
they can be stored in an external directory 
server. In a way, this directory acts as a 
central network configuration database. By 
separating the fairly static configuration 

35 information from the MAVS, we avoid syn- 
chronization issues when group definitions 
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change. The penalty however is that a 
directory access is necessary every time a 
group is resolved into its components. 

AMOs are programmed directly in 
5 Java. A core class provides the basic 

management services described above. Every 
AMO is then subclassed from the parent class 
and inherits automatically the basic access 
interface. In addition, the designer can 
10 implement the optional extended services by 
adding new service interfaces. Writing AMOs 
directly in a programming language has the 
following advantages : 

The development environment is 
15 much simpler since no AMO schema 

compilers are required (in contrast 
with the OSI model that uses a GDMO 
compiler for generating managed 
objects) . 

20 Some of the default object's 

functions can be overridden by the 
programmer to implement, for 
example, specific data collection 
and aggregation policies. 

25 Objects can be extended to 

provide customized high level 
services in addition to the fun- 
damental -get/set operations on 
their attributes. 

30 The Java runtime system 

supports dynamic class loading, 
which allows the integration of new 
AMO classes and the execution of 
manager-defined tasks, a capability 

35 also known as active management or 

management-by-delegation . 
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Managed Objects Visualization 
Model 

The MAVS, and the Marvel system in 
5 which it resides, was designed under the 

assumption that the majority of user clients 
have no prior knowledge of the information 
stored in Marvel servers and the methods used 
to access it. This allows clients to rely on 

10 the standard features provided by their 

distributed computing platform to download the 
necessary code to navigate through the 
database and to generate a graphical user 
interface to interact with the Aggregated 

15 Managed Objects. 

To accomplish this, the Marvel 
framework requires that every object be able 
to "visualize" itself by generating a user 
interface. There may, however, be several 

20 ways of visualizing an object depending on the 
capabilities of the client. For this reason, 
Marvel supports a small number of visual 
domains. For every supported visual domain, 
an Aggregated Managed Object must implement a 

25 visualization function capable of displaying 
the attributes of the object in that domain. 
For example, a Gopher system would require 
that the object be converted into a textual 
representation before it can be displayed. A 

30 web-based system would require that every 

object be converted into an HTML page, and any 
control actions for the object be implemented 
through HTML post operations and a CGI 
interface. Finally, a Java enriched web 

35 browser can download Java applets to provide a 
more interactive interface and use directly 
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distributed computing facilities such as CORBA 
and Java RMI to access the object's services. 

The latter visualization technique 
is of particular interest due to the wide 
5 acceptance of the world wide web and Java. As 
a result, object conversion to Java-enriched 
HTML is a mandatory service that must be 
provided by every Marvel object. Referring to 
Figures 6 and 7, the technique works as 
10 follows: First, the client invokes the 

object's to JeHTML ( ) method in one of the 
following ways : 

• by directly invoking 

the object's method through the 
15 distributed computing 

environment 50 , or, 

by indirectly making 
an HTTP get request supplying 
the object's name and address. 
20 The get request is then 

translated by the HTTP server 
53 to a call to the object's 
to JeHTML ( ) method, and the 
results are returned through 
25 the HTTP reply. 

Second, once the toJeHTML ( ) method has been 
called, the object generates an HTML page 51 
that can be viewed by the web browser 52. It 
does so by generating a default layout for the 
30 page, on which the values of the attributes 
will be displayed. Then, each attribute is 
instructed to convert itself into a Java- 
enriched HTML form. Simple data types such as 
strings and integers need only convert 
35 themselves into simple text. More complex 

data types (especially the ones representing 
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computed views of management information such 
as tables and time-series graphs) may choose 
to invoke a Java applet (by inserting the 
<applet> primitive) . The same holds for 
5 attributes that represent the object's control 
capabilities. When the applet is used purely 
for monitoring purposes, it is possible to 
supply all the necessary information inside 
the applet specification block through the 

10 <param> primitive. It is also possible to 

pass to the applet the name and address of the 
object, in which case the applet can interact 
with the object directly. This is required 
for applets that need to perform control 

15 operations on the object, or to refresh the 

displayed information after the page has been 
loaded. 

When the web browser 52 encounters 
the <applet> block 60 within the html page 51, 

20 it attempts to load the applet ' s code and any 
other Java classes needed for the applet 1 s 
operation. Java classes are always loaded 
from an HTTP server. 

As can be seen from above, a network 

25 manager can define how management information, 
collected from network elements, is aggregated 
into more useful abstractions and finally 
presented. Thus, as described above, the 
present invention allows for the automatic 

30 aggregation of network management information 
in spatial, temporal and functional forms, as 
well as the automatic visualization of the 
managed objects over the world-wide-web. 

In the foregoing description, the 

35 method and apparatus of the present invention 
have been described with reference to a 
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specific example. It is to be understood and 
expected that variations in the principles of 
the method and apparatus herein disclosed may 
be made by one skilled in the art and it is 
5 intended that such modifications, changes, and 
substitutions are to be included within the 
scope of the present invention as set forth in 
the appended claims. The specification and 
the drawings are accordingly to be regarded in 
10 an illustrative rather than in a restrictive 
sense . 
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What Is Claimed Is : 

1. A method for the automatic visualization 
of managed objects over the world-wide-web, 

5 the method comprising the steps of: 

receiving a request for visualization of 
network management information pertaining to 
one of at least one network element and at 
least one element management agent; 
10 identifying at least one attribute 

pertaining to the request for visualization of 
network management information; and 

generating an HTML page on the basis of 
the at least one attribute. 

15 

2. The method according to claim 1, wherein 
the at least one attribute is stored within an 
Aggregation Managed Object (AMO) . 

20 3. The method according to claim 2, wherein 
the Aggregation Managed Object is stored 
within a Management Aggregation and 
Visualization Server (MAVS) . 

25 4. The method according to claim 1, wherein 

the at least one attribute identifies at least 
one program applet. 

5. The method according to claim 1, further 
30 comprising the step of: 

retrieving at least one program applet 
identified by the at least one attribute for 
insertion into the generated HTML page. 

6. The method according to claim 5, wherein 
35 the at least one program applet is stored 

within an applet database. 
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7. The method according to claim 6, wherein 
the applet database is ccpntained within a 
Management Aggregation and Visualization 

5 Server (MAVS) . 

8. The method according to claim 5, wherein 
the at least one program applet is written in 
a JAVA computer programming language. 

10 

9. The method according to claim 1, further 
comprising the step of: 

sending the HTML page to a Web Browser 
from which the visualization request was 
15 recieved. 

10. The method according to claim 9, wherein 
the HTML page is sent to the Web Browser by an 
HTTP server . 

20 

11. The method accroding to claim 10, wherein 
the HTTP server is a Management Aggregation 
and Visualization Server (MAVS) . 

25 12. The method according to claim 1, further 
comprising the step of : 

displaying the HTML page through a Web 
Browser. 

30 13. The method' accroding to claim 1, wherein 
the request for visualization is in the form 
of a Uniform Resource Locator (URL) address. 

14. A method for the automatic visualization 
35 of managed objects over the world-wide-web, 
the method comprising the steps of: 



WO 99/30423 37 PCT/US98/25998 



receiving a request for visualization of 
an aggregated network management information 
object ; 

identifying at least one attribute of the 
5 aggregated network management information 
object ; 

applying a visualize function to the at 
least one attribute to create an HTML page. 

10 15. The method according to claim 14, further 
comprising the step of: 

retrieving at least one program applet 
pertaining to the at least one attribute. 

15 16. The method according to claim 15, further 
comprising the step of: 

inserting the at least one program applet 
into the HTML page. 

20 17. The method according to claim 14, wherein 
the at least one program applet is written in 
a JAVA computer programming language. 

18. The method according to claim 14, further 
25 comprising the step of: 

sending the HTML page to at least one web 
browser . 



19. The method according to claim 18, wherein 
30 the HTML page is sent to the at least one web 

browser by an HTTP server. 

20. The method according to claim 19, wherein 
the HTTP server is a part of .the Management 
Aggregation and Visualization Server (MAVS) . 
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21. An apparatus for the automatic 
visualization of managed objects over the 
world-wide-web, the apparatus comprising: 

an access interface for receiving a 
5 request for visualization of network 
management information; 

a persistent storage database for storage 
of at least one attribute pertaining to the 
network management information; and 
10 an HTTP server for generating an HTML 

page on the basis of the at least one 
attribute. 

22. The apparatus according to claim 21, 
15 further comprising: 

an applet database for storing at least 
one computer program applet relating to the at 
least one attribute. 

20 23. The apparatus according to claim 22, 
wherein the at least one computer program 
applet is written in a JAVA computer 
programming language . 

25 24. The apparatus according to claim 21, 
further comprising : 

a web browser for viewing the HTML page. 

25. The apparatus according to claim 21, 
30 wherein the at least one attribute is stored 
within an Aggregation Managed Object (AMO) . 



35 



26. The apparatus according to claim 21, 
wherein the HTTP server is a Management 
Aggregation and Visualization Server (MAVS) . 
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